第二大脑

主题

2026-08-24
568
2.1m

概念卡片：Dubbo RPC 框架 ​

一句话机制：Dubbo 把「远程调用」抽象成五个组件——Invoker（可调用的服务实例）→ Directory（实例集合）→ Router（路由筛选）→ LoadBalance（负载均衡选一台）→ Cluster（集群容错伪装）；Consumer 只持有 Cluster 伪装出的一个 Invoker，不感知背后有几台 Provider、失败了怎么处理。

服务调用链（5 个核心概念） ​

组件职责
InvokerProvider 一个可调用 Service 的抽象（封装地址 + 接口信息）
DirectoryInvoker 的集合（5 个 Provider = 5 个 Invoker），随注册推送动态变化
Cluster把多个 Invoker 伪装成一个，内置集群容错逻辑
Router按路由规则从 Directory 筛出 Invoker 子集
LoadBalance按负载均衡策略从子集选一个 Invoker 调用

Consumer 调用过程 ​

1. 服务有多个 Provider → Directory 里有多个 Invoker
2. Cluster 伪装成一个 Invoker（含集群容错）
3. Consumer 通过伪装 Invoker 调用
4. Router 按路由规则筛子集
5. LoadBalance 选一个 Invoker 调用；失败 → 走 Cluster 容错逻辑

架构三性 ​

特性说明
连通性三者长连接；Register 宕机不影响已运行调用（Consumer 有本地缓存）
健壮性Provider 宕一台，Consumer 自动连下一台
伸缩性Register 对等集群、Provider 无状态，都可动态扩缩

不变量（必须成立的约束） ​

  • Cluster 是关键抽象：它把「多实例 + 容错」伪装成「单实例」，Consumer 无需关心集群细节。
  • 负载均衡是软负载：Consumer 本地基于算法选实例，不经过中心代理。
  • 服务发现是 Client-Based（客户端拉取 + 订阅推送），Provider/Consumer 不感知对端 IP。

踩坑案例 ​

  • 现象：Provider 宕机后，Consumer 仍请求到旧实例报错。 原因：地址列表有推送延迟。解决：注册中心长连接 + 推送机制保证及时更新，Consumer 端配重试/容错策略兜底。

常见误解 ​

  • 以为 Dubbo 的负载均衡是服务端做的 → 是 Consumer 端软负载均衡，客户端自己选实例。
  • 以为 Consumer 直接连每个 Provider → 中间隔着 Cluster/Router/LoadBalance 的抽象链。

关联 ​

最近更新